Virtually all human activity in our modern society is now impacted to at least some degree by computer networks, although we are probably not always aware of that impact. One prime example is the Internet network, which has made its influence felt in ways not imagined just a few years ago. The vast amount of information made available thereby, and the ease of communication provided thereby between far-flung communities remains astonishing. Of course, there are smaller networks, some of which are sometimes referred to as LANs (Local Area Networks) which can be used within corporate organizations, certain government organizations or other limited areas which likewise provide techniques for enhancing human productivity.
Certain kinds of networks can employ a client workstation or user interface interacting with or controlling other sections of the network such as storage system sections. Because of today's widespread demand for computer networks, they may frequently be worked to their limits in whatever applications they are employed. In storage area networks (SANs) which encompass storage systems often comprised of multiple manageable components, connected servers (computers) and other network nodes including interconnects such as switches and hubs, it is a large task to manage all such nodes. This task may be handled through application of what is generically termed “management software”. This software normally runs on the client or user interface (UI) computer while, at the same time, also being deployed and running as agent software on various network nodes such as servers connected between the client computer and the storage systems, or, more recently, as agent software on storage processors (yet other computers) within such storage systems.
Accordingly, current management software is employed in certain client-server network architectures to manage disk arrays by communicating with its agent software that runs on the array's storage processors and on attached hosts (servers). But, to fully manage such an array, the user has to connect to and communicate with all storage-23 related nodes including storage processors and any attached hosts. This means that there are a vast number of individual connections and communications between the client (user interface) and various network nodes. This configuration imposes a heavy burden on the client computer in dealing with all of the nodes in its network.
As a simplified example of multiple UI-to-storage-system connections and communications in the prior art, refer to prior art FIG. 1, where a network is shown comprising user interface (client workstation) 100 and storage system 103. UI 100 is connected by two bus connections 101 and 102 to two storage processors 104 and 105 respectively. Those processors and disk drives 106 and 107 connected therefrom by network paths 108 and 109 respectively all are contained within storage system 103. (Cross coupling 111 and 110 between storage processor 104 and disk drive 107, and storage processor 105 and disk drive 106 respectively, are shown as dashed lines to suggest secondary or back-up connectivity.) As noted above, it would not be atypical for servers to be included in such configuration and located between the UI and each storage processor directly in the path of bus connections 101 and 102, but are not shown herein to enhance clarity of presentation.
As another example of multiple UI connection and communication shortcomings of certain prior art configurations, refer to prior art FIG. 2. The same network as that of FIG. 1 is shown, but, in addition, with a number of servers 213, 214, and 215 attached to the storage system via bus 212 (typically a Small Computer System Interface or SCSI bus), in a Storage Area Network (SAN) configuration and not attached in the server capacity or configuration mentioned in the prior paragraph. It can be seen that this configuration entails three more connections, 216, 217, and 218 between these SAN servers and user interface 100, with their respective communications. Boundary 219 circumscribes all storage-related nodes shown in this Figure, and is therefore a boundary for the SAN which could contain yet additional nodes. It should be understood that only three servers are shown herein for purposes of simplification, but, in reality, there can be up to fifteen or more such servers per SAN, each having its own connection and communication to the UI. And, there can be many SANs, perhaps 100 or more per UI, in a local area network (LAN) as a function of need. For this example, this translates to some 1700 separate and concurrent communication links to the UI!
Obviously, the point of these examples is to clearly show that the number of nodes per network requiring UI direct handling over dedicated lines can multiply significantly. The UI computer resource can be overburdened in managing each node in the SAN via a dedicated line to each such node. Furthermore, even before such managing can take place, this multi-connection arrangement requires the user to initially determine what hosts or servers are attached to the storage system and what their names or Internet addresses are, in order to properly deal with them. Thus, even if managing only a single storage system (even if employing only one array), the human user has to provide the client application software with the Internet addresses of all storage processors and all attached hosts which requires manual adjustments when new hosts are added or removed or when any addresses change. This increases the likelihood of imposing human error on the system. Additionally, since the client application software is required to communicate with multiple storage processors and all attached hosts, management performance is slow and only a limited number of nodes can be managed.
In the foregoing prior art examples, object-oriented programming languages such as “C++” have been employed. An object, in computer software terms, is a dedicated area of memory which can be thought of as an impervious “container” holding both data and instructions within itself, both defining itself and its relationships to other objects in the system or network. An object sends and receives messages to and from other objects, responds and reacts to such messages (e.g. commands) but is normally impervious to internal scrutiny. For example, a storage processor (which is a kind of computer) can be characterized as a “family” or “tree” of objects, where each such object may describe or relate to a specific detail in the processor (e.g. a fan, power switch, cache memory, power supply, disk drive interface, etc.), where these objects in the storage processor can send messages to each other and to other objects outside the processor. In prior art object-oriented computer networks, these objects defining various storage processors, servers and other nodes in the storage system, and relationships between them, were transferred back to the client application software running on the user interface computer where those objects were reassembled in the UI computer into a complete object tree reflecting the entire configuration of the storage system. This imposed a large burden on the user interface computer's processing power, which prevented it from performing other required tasks more efficiently, and from being optimized as a processing resource. In addition, to the overburdening shortcoming, users are sometimes confused by the complexity of having multiple operative connections into a single storage system or SAN.
These various shortcomings and problems of the prior art are overcome through the welcome arrival of applicants' present invention. Not only is the overburdening problem alleviated, but the overall configuration is simpler and more readily understood by users of the system.